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Introduction 


This document is intended as a guide to those who need 
to understand and/or write device drivers for tne XXDP-+ 
Ve system. Section 1.0 below describes the basic 
differences between V1 and V2 drivers. Section 2.0 
outines the physical layout of the driver. Section 3.0 
describes the functions performed by drivers while 
section 4.0 offers advice to those intending to 
maintain or write a device driver themselves. 


Throughout this document there are anny references to 
the mnemonics of the file structure. These ere listed 
in the glossary for convenience. A desription of the 
file structure may be found in the file structure 
document listed in the biblography. 


Differences between V1 ano V2 Drivers 


One major purpose of XXDP+ V2 is to simplify the 
maintenance of XXDP components. A facet of this 

i-th iS to make drivers as uniform as possible. 
o this : 


8) une tenn <a which seemed more file-oriented than 
device-oriented (e.g. file search) was migrated to 
a front-end, which is now incorporated in a 
version of UPD2 and other utilities. 


b) Read-only and Read-write functionality was 
recombined so that a single driver may be 
both by the Monitor and by utilities. 


c) Some functional aspects of individual drivers were 
changed. For instance, most drivers will now 
support two units (previously e different copy 
was needed for each unit). 


d) The sane of all drivers was made as uniform as 
poss:ble. 


e) Disk organization has been made uniform (MFD 
‘variety #1‘ has been retired). 


f) Some functional aspects of the Utilities were 
changed. UPD2 will no longer permit an Image 
copy between devices with differing sizes, and 
will not copy the Monitor during a File copy. 


——+ =. 
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Compatibility 


Coupee lei hi by between V2 and V1 has been maintained, 
with the following exceptions: 


1) The V1 DL and OM disk seveus did not allow 
for e 32k Monitor. If the V2 Monitor is installed 
on a V1 medium, the first file (or two) after the 
monitor eres will be corrupted. 


2) The MFD variety #1 has been retired for the DB, 
DD. DU and DY drivers. V2 drivers may be used to 
read or write Vl media. V1 drivers may be used 
to read V2 media, but not to write. (Except in 
the case: V1 MS drivers will not read V2 MS tapes. ) 


3) V2 media will have the octal constant 1002 at 
octal 1. di eplecenent 14 (the old MFD2 inter) in 
the MFD. V1 media will have some other value. 

The MFD is not currently read by most drivers, so 
this fact is not used. 


4) The V1 MM and MS tape layouts each had two Monitors 
at the tape — » selected according to what 
device was bei ag ed. The V2 layouts have only 

one Monitor as the first file on the tape. 


Device Driver Layout 


This section describes the lexical structure of XXDP 

Version 2 device drivers. The requisite components are 

outlined below with descriptions as to their functions 

and usage. Definitions of terms relating to file 

structure may be found in (AC-S866A-M0) CHQFSAO XXDP- 
File Structure Document. 


Driver Revision History 


This section contains a brief history of attributed 
source code revisions, as is stardard for DEC software. 
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Symbolic Equates 
Device-Independent Equates 


This section contains definitions for data structure 
offsets and other equates which are more or less common 
to all drivers. 


1) DIRBLK Offsets 


These equates describe the DIRBLK structure in 
the driver, discussed below. The DIRBLK contains a 
description of the (disk) layout. 


2) DDB Equetes 


These equates describe the ‘Device poper ipter 
Block’ (DDB), a data structure which is found in 
the utilities, end e subset of which is found in 
the Monitor. The DDB provides the driver's data 
interface. The driver's Parameter Table will 
overlay or be copied to the 


3) Device Command Codes 


These equates are the command codes, issued by e 
utility or the monitor, to which the driver 
responds. Some command codes, e. -? WRITE$, ere 
used by all drivers. Others me specific to 
device type (e.g. bad- -block ing)” or to the device 
itself (e.g.RFS FN- reformat RX02 single density). 


4) Parameter Table Equates 
When the driver is loadedby a ee its 
perameter table is copied into the . These 
equates are thus actually DDB offsets. 

5) Device Returned Status Byte 
These equates describe the meaning of the bits in 
the above-mentioned DVSB byte. They concern disk 
density and tape drive status. 


Device-Dependent Equates 


These are equates particular to the device and driver code. 


1) Program Equates 


These equates are typically mnemonics (e.g. LF 
or CR) used for convenience in the code. 


2) Device Equates 


These equates describe internal device codes, 
status words, commands, and packet formats. 
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Date Structures 
Device Parameter Table 


This date strehyre begins the driver's actual code. 
When the the Monitor is CREATED by the UPDATE utility 
the A -- 1S nded to the end of the monitor and 
vg A... overlays the Monitor's DDB. When the driver 

nr 2° utility, this table is copied into the 
utility s addresses being relocated ropriately. 
From this time on, the table is referenced largely 
through this DDB add the driver's copy is used only by 
the driver's INIT routine in Sune that. RS of the nex 
load. All driver routines assume that RS points to the 
command register entry in the DDB 


(Note: in order to save space, some of the parameters 
have been ohn INITIAL values and functions which are 
not related to their functions during execution. ) 


A Parameter Table Example is: 


PARAM: DISPAT ;DISPATCH ROUTINE 
-WORD "DZ ;DRIVER NAME 
.BYTE BBSUP$ :DEV ICE CODE 
.BYTE 44 s RETURNED STATUS CINITIAL os 
-WORD BCODE ‘BOOT CODE OFFSET 
UNIT: .BYTE O ;UNIT @ CINITIAL REV 
ERRB: -BYTE 0 ;ERROR STATUS CINITIAL PATCH #) 
CMDREG: 174400 ;COMMAND REGISTER ADDR 
WCOUNT: O ;WORD COUNT 
BUSADR: 0 ;BUS ADDRESS 
BLOCK: 0O ;BLOCK NUMBER 
COMD: 0 ; COMMAND 
DIRPTR: DIRBLK ‘POINTS TO 1ST DIR BLOCK. 
eo nH 0 FOR MONITOR COMPATIBILITY 


1) Dispatch Routine Address 
This entry is the address of the dispatch 
routine, which determines which driver routines 


to invoke. All driver services are provided 
through this entry. 


2) Driver Name 
This entry is the device's two byte mnemonic name. 


er ee ae = ae = 
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3) Device Code 
This static byte is used to indicate that the 


device has special features of interest to 
utilities. Current flags are: 


BBSUP$ - Device provides bad block support. 
NODIR$ - Not a directory device 

TAPED$ - Tape device 

REFDN$ - Supports single/double density reformat. 
MULUN$ - Driver supports 2 units/driver 

NORENS - Device does not support file rename. 
FLOAD$ - Device may have floating address. 


4) Device Status 


This byte is returned by some drivers in response 
to inquiries concerning disk density or tape 
status. Current flags are: 


Disk is double density 
is at physical bot 
Tape is at tape mark 
EOTTP$ Tape is at ohysicel eot 


(The INITIAL value of this byte communicates a device 
type code to the Moniter :mmediately after the 
driver is loaded. ‘See sprendix D.) 


5) Boot Code Offset 


This entry contains the displacement to the boot 
code, i.e. to the end of driver code. This is 
used by the Monitor and does not further concern 
the driver itself. 


6) UNIT 


This byte entry communicates the device unit # 
ae oe This is commonly eddressed as 
(The INITIAL value of this byte communicates the 
version number of the driver.) 


7) ERRB 


This byte entry is used by the driver to — 
communicate errors and (sometimes) attention 
conditions. It is tested immediately prior to 
driver exit (as XER(R5)). 

(The INITIAL value of this byte communicates the 
patch number of this driver. 


8) CMDREG 
This is the address of the primary device command 


register. It is the focus of the DDB and is used 
by the driver to access all device registers. 


wo 
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9) WCOUNT, BUSADR, BLOCK 


These entries are used to communicate to the 
driver, the count, address, and block number of 
e transfer command. 


10) COMD 


This entry contains the coded command to be 
performed by the driver. This code is 
interpreted in the driver's — routine. 


11) DIRPTR 


This entry points to the driver data structure 
DIRBLK, a table which describes the physical 

leyout of a disk. This pointer is the only . 
exception to the rule that local entries in this 
table (as opposed to their Copies in the ) 

are not used. The driver's INIT routine may toggle 
this pointer for some “two-unit” drivers to point to 
an alternate DIRBLK structure to be active on the 
next load. This feature permits one driver to be used 
with two units with differing densities, etc. 


DIRBLK 


This data structure Sommunigeten particulars of the 
device's physical layout. Its first sgyere: entries 
mirror the structure of a variety #2 MFD, which is now 
used for non-bad-blocking devices as wel i Note that 
for non-bad-blocking devices, the date contained in 
DIRBLK is constant and the MFD need ~—— be actuall 
read. For some drivers which ouspers two units, DIRBLK 
will be replicated, and DIRPTR will be toggled back and 
forth by the driver's INIT routine. 


Local data 


This section contains data structures used someenmn ly Dy 

oe driver to store state information, construct pac a 
tc. Some unit-dependent local data may be appended 

DIRBLK to take advantage of DIRBLK switching for two- unit 

drivers. 


Error Messages 


This section contains the error messages printed by the 
driver. The utilities may append information to suc 
messages, e.g. if the driver prints By ERR", the utility 
will note the error thro the error byte XER(RS), and 
may append, for example, “IN INPUT DIRECTORY”. 


— ———— ee ee oe ee ee ee rn 
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Executable Code 
DISPATCH Routine 


The dispatch routine receives control from the utility or 
monitor, examines the command code in the DDB, and gives 
control to subordinate routines. Dispatch may, in 
addition, perform code sequences common to its sub- 
ordinates or indeed perform some simple commands. Just 
er Ler to exit, the ae woriee "tests the error byte 
ERCRS) so that we calling utility may make an immediate 
branch on error. me present. some dispatches are "test 
and call” and some table driven. In drivers with more 
than 4 such tests, a table driven approach may save 
space. 


INIT Routine 


The init routine receives gontrel ye dispatch. Its 

primary function is to perform any eveiee initieal- — 

ization and to set local DIRBLK rng les to reflect unit 

characteristics. It is assumed to have been called 

immediately after the driver is loaded. Init may also 

a euxillary functions, such as determining device 
nsity 


DRIVER Routine 

The driver routine receives control from dispatch. It 
commonly handles I/0 transfers. In many cases, the code 
in this routine is largely unchanged from that in V1. 


Auxillary Routines 
These routines are called by DISPATCH, INIT and DRIVER. 


— ee fem —- —— ae & 
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Device Drivers Functions 
All Drivers 


There is a minimal set of functions which all drivers are 
expected to perform: 


This function is invoked once per device-unit, 
either after the Monitor has been loaded or i 
after a utility ‘loads’ a driver. Note that i 
utility finds the requested driver to be already present, 
it will not load a vreau omy. Before INIT$ is invoked, 
parameter table information has been copied (or in the 
case of the Monitor, overlayed) on to the DDB; in 
particular DIRPTR has been converted from relative to 
absolute address (but only on a fresh load). 


Tasks to be performed at this time include device 
initialization (e.g. DU performs an initialization — 
sequence at this time when the value of a locel variable 
signifies that it is a fresh ‘load') and intialization 
of local variables. Disk drivers which s rt bed- 
blocking use this occasion to read the disk MFD and 

set DIRELK variables accordingly. Some drivers which 
support two units with differing characteristics (e.g. 
density) will toggle the (local) pointer DIRPTR at this 
time so that on next ‘load’, a different DIRBLK will 


be used. 


You will see that, in those drivers which have e GTMFD1 
routine to read the MFD, a ee XXMFID is checked 
before any disk read is done. This flag is raised by 
the driver loading routine in the utility when a ZE 
directive is in progress - in order to avoid reading 
junk from a disk which is about to be cleared. The 
IRBLK structure is updated by the utility during the 
ZERO execution. 


diately 
% 


This function is invoked by the Monitor to read some 
blocks from the Monitor image, presumably after possible 
corruption. 


At this time the code relocates the requested block 
number by the starting Monitor block number. The code 
may assume that this entry in DIRBLK is either a 
constant or has been updated during INIT$ processing. 


o— — ——__ —— ee « 
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This function is used by all drivers except LP:. 

It is invoked by the Monitor or the utility to read 

a block or series of blocks from the device. The word 
count, buffer address and starting block number (for 
direct access devices) are found in the DOB. 


It is the driver's function to convert the word count 
and block numbers if necessary, to initiate the transfer, 
end to wait until successful completion. If an error is 
detected, the driver may try to effect recovery (e.g. 
several disk drivers now have ECC correction routines). 
If recovery is impossible, failure is communicated by 


setting the XER byte in the DDB to a non-zero value. 


This function is used by all drivers. All comments 
concerning READ$ above are applicable here. 


—_— —— © wee rw — = ee 
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Disk Drivers 


Disk devices are all directory structured. This is 
signalled to the utility by having a positive first entry 
in the DIRBLK table. A disk driver may have functions in 
addition to those above: 


REDSFN 

This function requests the read of an absolute 
cylinder/track/sector from a bad-blocking device. It 
is invoked by the ZERO command execution in UPD2. 
UPD2 places the cylinder, track and sector addresses 
of the bad-block file (determined from DIRBLK) into 
the DDB and issues the call. 


The format of the bad-block file is a list of 
cylinder/track/sectors. The ZERO routine in UPD2 issues 
e CMPSFN to convert these to block numbers, which it 
uses to set the appropriate bit-maps. 


DEN$FN 


The ZERO routine in UPD2 needs to know the disk density 
to find the correct location of the bad-block file. 


The driver returns a flag in the DDB status byte DVSB. 


0 = single densit 
1 = debe dene ty 


RFS$FN,RFDSFN 

The DY driver performs hardware re-formatting of a disk 
to single or double density (as communicated to UPD2 
ereun the ZERO command). 


. - —_——_ _- ——— — - 
ne — owe ——_—_——_— 
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Tape Drivers 


Drivers for tape devices (communicated via the device 
code byte in the DDB and by a negetive first word in 
DIRBLK) provide a variety of functions not needed for 
disk devices. Tapes ere not directory devices - every 


file is preceded by a header which contains the file name. 


The logical end of tape is a double EOF. In addition to 
those functions listed as common to a)l drivers above: 


This function is invoked to set up the tape controller 
for subsequent commands. 


This function is called to read a header. 
SEF STP 


This function is invoked to skip to an EOF, i.e. to 
skip the remainder of a file. 


This function is called to write en EOF on tape. 
SETSTP 


This function is called to skip to the logical end 
of tape, i.e. after all files. 


STASTP 

This function is invoked to return the tape status 

Cat gee sicel EQT) through the device status 
byte in the 6. The two existing tape drivers, MM 
and MS approach this yi cnagees MM backspaces the 
tape and then forward spaces. If BOT was detected 
during the backspace, this is returned as status. 
Otherwise the stetus detected vowed the forward space 
is on irs, Lata MS driver interrogates the controller 
in real time, 
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Writing a Driver 


The best approach to writing a driver is to model it on 
existing ones. The drivers that presently exsist provide 
@ wide variety from which to choose, and are brief y 
characterized along several dimensions at the end of this 
section. Some points to note: 


1) Much of the driver preamble is device-independent and 
may be copied wholesale. Look at the preamble of UPD2 
to determine the symbolic command codes etc. with 
which the utilities and drivers commun 


icete. 

2) The device-dependent components of the preamble 
follow informal conventions, e.g. control register 
names are often similar from device to device. You 
may be able to copy this, with minor changes, from 
some driver with ea similar communications structure. 


3) The parameter tables of all drivers sre quite similer. 


4) The DIRBLK specifies the eran layout of a disk 
device. Be careful how you ay out a disk structure - 
do not lock yourself into a structure which cannot be 
easily expanded to meet similar but larger devices. 
For example, you might want to put the itor image 
towards the beginning of the disk, before the UFD and 
Bitmaps, so that the bootstrap routine doesn't have 


to contend with these ereas as they change from device 


to device. 
Ar example of ea good structure might be: 

Block Purpose 

0 Secondary bootstrap 

1 MFD1 

3 Stert of Monitor image 

| ¥ First UFD block 

35. +N First bit map 

35. -Ne- M # of blocks to presllocate 
Remember that, even a 2 they are linked, UFD and 
bit map space ere allocated conti ly by UPD2 at 


device ZEROing. It is, in fact, this contiguity which 
results in the possibility that the actual parameters 


may differ among bad-blocking devices. 


5) The DDB error byte ERR(RS) is used to communicate 


failure. The driver must test this byte immediately 
before exiting. Note thet the polarity of this device 
is used to communicate different flavors of failure: 
€e.9. -1 often means ‘device full’. 


So EE TNT ~~ 
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If you plan to have your driver ouppert 2 disparate 
devices at the same time 60.9. bad-blocking devices 
ere disparate because the actual location of some 
things may change. There is a limit to this: the 
boot routine may assume a constant location for the 
Monitor image), you may want to toggle between two 
DIRBLIK's. Be careful, in this case, to remember that 
the parameter table ectueliy overlays the DDB when 
the driver is linked with the Monitor; toggle before 
any changes are made to DIRBLK. 


The DRIVER routine in many drivers disambiguates some 
of the commands. This is due to historical reasons 
and commonality of some code. 


Driver code must be location-independent. In part- 
icular, this means that if addresses of locel data 
are manipulated, they must be calculated dynamically 
rather than by the linker. E.9. 


MOV #TABLE.RO ; will not get the address of 
; TABLE 


but 


MOV PC,RO 
ADD #TABLE-..RO ; will work 


All code must be processor independant. 


The disk layout (reflected in DIRBLK) of some bad- 
blocking devices depends on the medium density. When 
e driver is ‘loaded’ as e result of a ZERO command, 
the MFD refreshed indicator in the DIRBLK is set by 
UPD2 prior to invoking the INIT function. This is 
tested in the driver's GIMFD1 routine to Ss an 
MFD read (the MFD may be junk). The UPD2 ZERO 
command will issue ea DENSFN to the driver to 
determine the disk density, and will compute the 
bad-block file and bad-block —— attributes — 
(first UFD, bitmap, and Monitor) accordingly. It will 
not, however, set up the remaining densi ty-dependent 
DIRBLK entries: this should be done by the driver's 
a oat with consideration that the MFD might not 
read. 


The MFD for all devices is written by UPD2 during a 
ZERO command, and, for bad-blocking devices, must be 
referenced (because it contains variable information) 
by the driver during an INIT function to update the 
DIRBLK. The variables to be updated are starting UFD, 
Monitor, and bitmap block mumbers. Except for this 
reference, the driver need not concern itself with 
the “FD variety or structure. 


—_—_——< = 
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5.0 Device Driver Cheracteristics 


DS - RJPO4,5.6 


oC 


DL 


Type 
Bad-block ing 
Error-recovery 
Commun ications 
DIRBLK 


Two units/driver 
Dispatch 


- TUS8 


Type 
Bad-block ing 
Error-recovery 
Commun ications 
DIRBLK 


Two units/driver 
Dispatch 


- RLO1,02 


Type 
Bad-block ing 
Error-recovery 
Commun ications 
DIRBLK 


Two units/driver 
Dispatch 


- RKO6,7 


Type 
Bad-block ing 
Error-recovery 
Commun ications 
DIRBLK 

Two units/driver 
Dispatch 


- RMO2,03 


Type ; 
Bad-blocking 
Error -recovery 
Commun ications 
DIRBLK 

Two units/driver 
Dispatch 


Disk 


No 
ECC correction,retry 
Device registers 


Disk 

Yes 

Retry : 

Device Registers 

Variable according to bad-block ing 
end density. 


Disk 

Yes ; 

ECC correction,retry 

Device Registers ; 
ver ieee according to bad-blocking 


€5 
Table 


Disk 

Yes d 

ECC correction,retry 

Device Registers ; 
ver ible according to bad-blocking 
es 

Table 


—— — —— =e © 
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DU - UDA 50,RD/RX 


DY 


LP 


MS 


Type 
Bad-block ing 
Error-recovery 
Commun ications 
DIRBLK 

Two units/driver 
Dispatch 


- RX02,01 (does not 


Type 
Bad-block ing 
Error -recovery 
Commun ications 
DIRBLK 


Two units/driver 
Dispatch 


- Line printer 


Type 
Bad-block ing 
Error -recovery 
Commun ications 
DIRBLK 

Two units/driver 
Dispatch 


- TMO2 


Type 
Bad-block ing 
Error -recovery 
Commun ications 
DIRBLK 

Two units/oriver 
Dispatch 


- 1$04/TS11 


Type 
Bad-blocking 
Error-recovery 
Commun ications 
DIRBLK 

Two units/driver 
Dispatch 


Fe 
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Disk 
Transparent to driver 


mMSCP 
Variable according to drive capacity 


ee 
Test and call 

boot RX01) 

Disk 

No 

Retry 

Device Registers 

Ver ieble according to RxX01/02 


es 
Table 


Line printer 
Huh? 


Device papietere 
Constant 


No 
Test and cell 


Tape 


Retry : 
Device registers 
Constant -1 

Yes 

Table 


SEQ 0018 


Ge 


Page 19 
SEQ 0019 
6.0 GLOSSARY 
IRG - Interrecord gap. The gap that is written 
between records on magtape. 
MF D - Master File Directory 


RAD-5O0 - RADIX-50. A method of encoding 3 ASC11 
characters into one 16 bit word. 


UFD - User File Directory. 
VIC - User Identification code. 
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Appendix A - Driver and Boot Example 


The following is an example of a working driver (DB:), edited 
slightlly to explicate structure. 


-NLIST CND 
-SBTTL ORIVER REVISION HISTORY 


; REV DATE CHANGE 
; 1.0 31-JUL-78 INITIAL ISSUE 
: 1.1 17-NOV-78 MAKE COMPATABLE WITH BIG DRVCOM 
; 2.0 11-AUG-80 XXDP+ V1.1 COMPATIBLE 
, REMOVED READ-ONLY CODE 
ADDED XERCRS) AS RESULT STATUS 
: ADDED INIT ROUT 
, REMOVED CLEAR MAPS ROUTINE 
; 21-FEB-84 CHANGE FOR V2, INCLUDING ECC CORRECT 
06-MAR-84 TWO UNITS/DRIVER - GOT RID OF GTMFD1 
18-MAR-84 TABLE DRIVEN DISPATCH 
25-APR-84 INITIALIZE RETURNED STATUS BYTE 
PAGE 

_NLIST ME,CND 

"NLIST MC 

"LIST  MEB 


_—s DEVICE-INDEPENDENT EQUATES 


XDIR =0 31ST DIR BLOCK. 
XDIRN =2 ;# OF DIR BLOCKS 
=a. ;1MAP BLOCK # 
XMPN = ;# MAP BLOCKS 
XMFD1 =10 ;MFD1 BLOCK 
XVERS =12 ;XXDP_ VERSION # (1002 = VERSION 2) 
AMXBK «= 14 sMAX BLOCKS WORD. 
RSBK =16 # OF BLOCKS TO RESERVE. 
ITLVE =20 SINTERLEAVE FACTOR. 
BOTBK  =22 ;B00T BLOCK. 
K =24 ;MONITOR CORE IMAGE BLOCK. 


MNB 
XMFID =26 :MFD REFRESHED INDICATOR. 


= ————— + See SS Oe —_—-e -— —_— 2-0 ee ee ee ee ee -_ - 


SEQ 0020 


SEQ 0021 


DEVICE DESCRIPTER BLOCK (DDB) EQUATES 
: DDB OFFSETS FOR R/W DRIVER 
ODE OFFSETS FOR MONITOR ARE A SUBSET 


lll ee ee a a a a ee a 


XREW = -50  ;INDEX TO INHIBIT REWIND INDCATOR 
XWCTR = -46 ; INDEX TO WRITE COUNTER 
XWILD = -44 +#;INDEX TO WILDCARD INDICATOR 
XFLCNT = -42 ; INDEX TO FILE COUNT 
XSVMAP = -40 ; 
XSVBLK = ss 36 v 
XSVDAT = -34 F 
XBKLGT = -32 ; 
XLSTBK = -30_ ; 
UF s -26 7 
XSVCNT = -24 + 
xs = -22 2 
XSVEXT = -16 ; 
XiSTBK = -14_ ; 
XSV = -12 ;INDEX TO SERVICE ROUTINE (DRIVER) 
XDN = -2 :DRIV E NUMBER INDEX 
XER = -] ;RESULT STATUS 
XCM = 0 ; INDEX TO COMMAND REGISTER 
XWC = 2 ; INDEX TO WORD COUNT 
XBA = 4 ; INDEX TO BUS ADDRESS 
XDT = ; INDEX TO BLOCK NUMBER OR TAPE SKIP ¢# 
XxCO = 10 ;INDEX TO COMMAND 
XDR = 12 ;INDEX TO 1ST DIR BLOCK POINTER 
XXNAM = 14 +#;INDEX TO ASCII NAME IN DDB 
XBC = 16 ;INDEX TO REQUESTED BLOCK COUNT 
XNB = 20 ;INDEX TO LAST BLOCK # ALLOCATED 
XCKSUM = 22 +#;CHECKSUM CALCULATION IN SEARCH 
SVC = XSV ;ALTERNATE NAME 


INIT$ = 0 ; INITIALIZE DEVICE AND BRING ON LINE 
READ$ = 1 ; READ 
WRITES = 2 ; WRITE 
RES$FN = 3 ; RESTORE FUNCTION FOR MONITOR 
DIS = SVC =: DISPATCH TABLE 
; CODE BYTE 


; MULUN$ = 100 ; DRIVER PERMITS MULTIPLE DEVICES 


—=- — —_ —- ee | ee eee — _ 


. PAGE 
.SBTTL DEVICE-DEPENDENT EQUATES 


ie ee ee ee 


SEQ 0022 


RPWC s;RJPO4 WORD COUNT REGISTER 

RPBA ;RJPO4 BUS ADDRESS REGISTER 

RPDA ;RJPO4 DESIRED SECTOR/TRACK REGISTER 
RPCS2 REGISTER 2 


;RUPO4 CONTROL STATUS 
:R GISTER 


EGISTER 
;RUPO4 DESIRED CYLINDER REGISTER 
;RUPO4 ECC POSITION 
sRJPO4 ECC PATTERN 


;RJPO4 READ COMMAND 
;RUPO4 WRITE COMMAND 


g 
2 


oR 
ASA 
at 
m 
‘Ail RRewEST ON 


-~ -< ———_——_—— ee — — Fe —— oe = © —— ee — 2 eee —— - - 


PAGE 
SE 
-SBTTL XXDP DEVICE DRIVER PARAMETER TABLE Q 0023 


: D DEVICE -DRIVER PARAMETERS 
THESE PARAMETERS ARE USED IN COMMUNICATION WITH THE UTILITY 


PARAM: DISPAT DESPATCH ROUTINE 
-WORD “DB ;DRIVER NAME 
.BYTE MULUNS ;DEVICE CODE 
BYTE i ‘RETURNED DEVICE STATUS CINT DEVICE TYPE) 
-WORD BCODE ;BOOT CODE OFFSET 
UNIT: BYTE ‘A ; UNIT CINTIAL REV # A ) 
ERRB: .BYTE ‘2 ‘ERROR “STA TUS CINTIAL PATCH # 1) 
CMDREG: 176700 : COMMAND REGISTER ADDR 
WCOUNT: 0 COUNT 
BUSADR: 0 ‘BUS ADDRESS 
BLOCK: 0O :BLOCK NUMBER 
COMD : 0 AND 
DIRPTR: DIRBLK POINTS TO 1ST DIR BLOCK. 
ASNAM: 0O :FOR MONITOR COMPATIBILITY 


. —- —_—- = 
= — © © -—- ——_—— =e « —= 


. PAGE 
-SBTTL DIRBLK TABLE SEQ 0024 


DIRBLK: 3 ;1ST UFD BLOCK ADDR 
170. ; ER OF UFD BLOCKS 
173. ;1ST BIT MAP BLOCK ADDR 
50. ;NUMBER OF MAP BLOCKS 
1 ;MFD1 BLOCK ADDR 
1002 ;VERSION 2 FLAG (NOT UPDATED) 
48000. “y NUMBER OF BLOCKS ON DEVICE 
255. # OF BLOCKS TO PREALLOCATE AT ZERO 
1  INTERLEAVE “y ACTOR 
0 ;B00T BLOCK 
MONBLK: 223. ; MONITOR CORE IMAGE BLOCK # 
0 ;MFD REFRESHED FLAG. O=NO, NON 0=YES 


ECCPAT: .WORD 0,0 ;STORAGE FOR ECC CORRECTION 


.SBTTL ERROR MESSAGES 


MWTERR: .ASCIZ <40><40>'? WT ERR’ 


MRDERR: .ASCIZ <40><40>'? RD ERR’ 
ILLERR: oa <40><40>'? ILLEGAL CMND ERR’ 


—_—_o- — ee © er ee —-« we meee —<-- = 


. PAGE 


.SBTTL MAIN DISPATCH ROUTINE 
je EROR SRE SERE EERE ESSER EERE EE EEE EEE EERE REESE EERE KES 


; DISPATCH ROUTINE FOR DRIVER 


M2 


; THIS ROUTINE RECEIVES CONTROL FROM A UTILITY 
; OR DRVCOM. IT EXAMINES THE COMMAND CODE IN 
; XCOCRS) IN THE DDB, AND CALLS THE APPROPRIATE 
; LOCAL FUNCTION. 
; INPUT 
; XCOCRS) 
; OUTPUT: 
; CALLS APPROPRIATE INTERNAL FUNCTION. 
; TESTS ERROR BYTE BEFORE RETURN 
; REGISTERS CHANGED: 
J SSSSSSSSSSSSESSESSESSSSSSESSSSSSSESSESESSEEKESESESEEEEEEEKREEEEEEESEEEREEDSE 
DISPAT: MOV RO, -(SP) ; SAVE 
MOV R1,-(SP) 
MOV R2,-(SP) 
MOV PC,R1 ;TRUE ADDRESS 
SUB #.,R1 ;DIFFERENCE BETWEEN TRUE & 
; APPARENT 
MOV #TABLE-2,R0 ;D0 A TABLE SEARCH 
ADD 1,R0 ;GET REAL Ss 
10$: TST (RO)- ;TO NEXT FUNCTION 
TST (RO) ;END OF TABLE ? 
BMI 110$ ;MI = YES 
CMP (RO)+, XCOCRS) ;I1S IT OUR FUNCTION ? 
BNE 10$ ;NE = 
ADD (RO),R1 ;ELSE GET REAL ADDRESS 
JSR PC,(R1) ; T 
BR 240$ ;AND LEAVE 
; HERE IF ILLEGAL FUNCTION 
110$:  $ABORT #ILLERR ;NOT LEGAL COMMAND 
MOVB  #-1.XERCRS) ; SIGNAL 
240$: MOV (SP)+,R4 ; RESTORE 
MOV (SP)+,R3 
MOV (SP)+,Re 
MOV (SP)+,R1 
MOV (SP)+,RO a et 
TSTB  =—s_- KER(RS) :Set error indicator 
RTS PC 
sFUNCTION TABLE - FIRST ELEMENT IS FUNCTION, SECOND IS ROUTINE 
TABLE: .WORD INIT$,INIT ; INITIALIZE 
.WORD RESS$FN,RESTOR ;MONITOR RESTORE 
"WORD READ$,DRIVER “BLOCK READ 
“WORD WRITE$,ORIVER “BLOCK WRITE 
"WORD -] “END OF TABLE 


_— — fee —— ——— —- « 


——_—— 


SEQ 0025 


N2 


. PAGE 

.SBTTL MAIN ROUTINE: INIT 

po OOS CREE EEEEEREREEE EERE EEEREEEEEEEEEEREEEEEEEES EEE ES EEE EEE 
;ROUTINE TO INITIALIZE THE DEVICE 


INPUTS: 


‘OUTPUTS: 
;ROUTINES CALLED: 


; 
;REGISTERS CHANGED: NONE 
f— SER EREE EERE SEES EERE EERE SESE REE EEEEEEEEEEEEREREEEREE EEE EEE 


INIT:  CLRB XERCRS ) ASSUME GOOD RESULT 
RTS PC 


—_— —-—— 


SEQ 0026 


See ee eee ee we 


. PAGE 

SEQ 0027 
.SBTTL MAIN ROUTINE: RESTORE 
TEP iii iiiiriiiiiiiiitiiitiiiiiiiiiiiiit 


ROUTINE TO READ PART OF THE MONITOR CORE IMAGE 


CALL AS FOLLOWS: 

; PUT BLOCK NUMBER RELATIVE TO MONITOR IN XDT(RS) 
; PUT NUMBER OF WORDS TO READ IN XWC(RS) 

; PUT ADDRESS TO READ INTO IN XBA(RS) 

: PUT REWS$FN IN XCOC(RS) 

: JSR PC, aDIS(RS) 

; GOOD RETURN:DATA READ 

; ERROR RETURN: DIS TESTS XER(RS) BEFORE RETURN 

; ROUTINES CALLED: DIS(RS) 


REGISTERS CHANGED: NONE 


F ~~ SSSSSSSSHSSSSSSSSSSSSSSHKSSSESSSHESESSSSESSESESESEKESEEEEEEEEEEEEEEES 


RESTOR: ADD MONBLK,XDTCRS) ;MAKE BLK NUMBER RELATIVE TO 0 
MOV READS, XCOCRS) ;00 A READ FUNCTION 
Pe a—_ ;LET DRIVER DO IT 


- LT TTT 


a 


. PAGE 
.SBTTL MAIN ROUTINE: DRIVER 


Fe CSSSSSSSSHSSSSSSSSSSSSSSSSHESSESESESESES EEE EKREKEEEKEEE EEE EES 


; READ-WRITE DRIVER FOR THE RUPO4 


; CALLED FROM DISPATCH 
PERFORMS READ$ AND WRITE$ FUNCTIONS 


: GOOD RETURN: 
: TRANSFER EFFECTED, XER(RS) CLEARED 
; ERROR RETURN: 

MESSAGE TYPED, XER(RS) NONZERO 

; REGISTERS CHANGED: 


RO,.R1,R2,R3,R4 
ee PPPS PIII iiiiiiiiiiiiiiiiiiiiiiiiiiii iy 


DRIVER 
CLRB  ~—s._- XER(R5) ;ASSUME SUCCESSFUL RESULT 
MOV #11. ,R4 :# OF TIMES TO RETRY ON ERRORS 
RPDRV1: DEC 4 ;SHOULD WE CONTINUE? 
BLE 333 :NO,SO REPORT ERROR 
MOV (RS).R3 sDEVICE ADR 
MOV XDN(RS), RO ;GET UNIT NUMBER 
BIC $177400.R0 STRIP OFF ANY JUNK 
MOV RO. RPCS2(R3) ;LOAD RESULT INTO RPCS2 
MOV €10000,RPOF(R3)  ;SET 16 BIT FORMAT IN RPOF REG 
MOV #23,(R3) ;D0 A PACK ACK TO SET VV BIT 
MOV XWC(RS).RPWC(R3) ;WORD COUNT 
NEG RPLIC(R3) ;TWO'S COMPLEMENT OF WC 
MOV XBA(RS), RPBACR3) ;BUS ADR 
MOV XDT(R5).R1 ;BLOC NUMBER 
MOV 822. R2 s22 SECTORS PER TRACK 
L 
is: SUB Re. ;DIVIDE BY SECTOR SIZE 
L 
INC 7 ;UP TRACK COUNT 
28: ADD R2,R1 sWENT TOO F 
nOy Ri. -(SP) PUT SECTOR @ ON STACK 
L 
MOV #19. ,R2 :19 TRACKS PER CYLINDER 
3$: SUB R2,R0 sDIVIDE BY TRACKS PER CYL 
BLO 4$ :TO GET TRACK AND YL ‘ 
INC Ri ;UP CYL COUNT IN 
BR 33 "RO IS HOL DING TRACK $ 
4$: ADD R2,RO ;MAKE UP FOR GOING 190 FAR 
SWAB sa RO ; MOVE TRACK @ TO LEFT 
BIS (SP)+,RO ;0R IN RIGHT SIDE (SECTOR) 
MOV RO, RPDA(R3) :T0 DSK ADR 
MOV R1,RPDC(R3) :T0 DSK CYL ADR REG 
CMP #READ$, XCOCRS) 31S A READ ? 
BNE 10$ ;NE = NO, MUST BE A WRITE 
MOV #R JREAD, (R3) :ELSE START IT 


30$ 
10$: MOV @RIWRIT, (RS) ;START WRITE 


TT A TS TT i 


SEQ 0028 


#DONE !ERR 
oot OR, (R3) 


20$ 
BE QOCUS AMERICAS) 


#100, RPER 
Sas ER1(R3) 


AT et R 
(R3) _— 
31$ 
20$ 


(R3),R 
ne RPCS2(R3) 


) 


mc 
» PREA 
36$ vs 
MW TERR 

O$ 

#MRDERR 

PC 


;DONE OR ER 

;NEITHER — 

;WAS A DATA 

; 

EQ. Nd CHECK ERROR? 

; ; | 
Nees i3 IT CORRECTABLE? 
;ELSE CORRECT IT 


;CLEAR ERR 
WATT TILL DONE 


;AND LEAVE 


;SAVE ERROR INF 
a tLEAR 


;WAS IT HAR 
— D ERROR? 


; INDICATE ERR 
WAS ERROR ON READ? 


;YES 

;PRINT WRIT 
;RETURN TO EALLER 
;PRINT READ ERROR 


SEQ 0029 


. PAGE 


* 


.SBTTL ROUTINE ECCCOR 


FP PSSSSSSSSSSSSSSSSSSSSSSSSESS SSSA SSSSESSESESEREKERESEEESEEEEKEE EEE 


; CORRECT A SOFT ECC ERROR 


ALGORI 


THM ADAPTED FROM THAT IN CZR6PD) 


USES HARDWARE ERROR BURST PATTERN TO CORRECT A FAULTY 
SEQUENCE OF UP TO 11 BITS 


; CALLED BY DRIVER 


DATA CORRECTED IN BUFFER 
; REGISTERS CHANGED: 
RO,R1,R4 


; GOOD RETURN: 


» « - 9naseoenbnanesenbbebenaasenennnensbannenneednnnensasseseosete 


ECCCOR: — 


—“—,- sERROR BURST PATTERN 
ECCPAT+2 oy SHIFT INTO THIS 


R3, -(SP) :SA 
RPECI(R3),R1 SERROR BURST POS COUNT 
XBA(RS) RS ;BUFFER ADDRESS 
XWC(R5) 2 RO ; WOR 
R4 ;NOW BYTE COUNT 
R3, -(SP) ;CALCULATE END OF 
R4,(SP) 3 

1 ;CONVERT TO BIT DISPLACEMENT 
R1,RO 3; SAVE 
Rl ;COMPUTE BYTE DISPLACEMENT 
Ri 

#1,R1 ;WORD DISPLACEMENT 
R1.R4 ;ERROR WITHIN TRANSFER? 

10$ :HIS = RET 
R1,R3 [COMPUTE BUFFER ADDRESS OF ERR 
#177760,R0 : STARTING BIT DISPLAC IN WORD 
5$ ;EQ = ON WORD BOUNDAR 
ECCPAT :SHIFT PATTERN 1 BIT LEFT 
ECCPAT-2 MAN'S ASHC 
RO SOC EREHENT COUNT 
3$ ;UNTIL DONE 

(R3),RO CORRECT FIRST WORD 
ECCPAT.R1 WITH XOR OF PATTERN 
ECCPAT, "(R3) ‘POOR MAN'S XOR 
R1.(R3)- 

(SP),R3 ;CHECK IF SECOND WORD IS 
10$ ;IN BUFFER, EQ@= NO, ALL DONE 
(R3),RO ;ELSE DO NEXT WORD 
ECCPAT+2,R1 
ECCPAT+2.(R3) 
RO.R1 
R1,(R3) 

(SP). ;BUMP TEMP STORAGE 

($P)+4R3 


Oe en ee cee eee eee . = 
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SEQ 0030 


ra 


SEQ 0031 


‘SECONDARY BOOT CODE AREA 
BCODE : 


. PAGE 
.SBTTL BOOTSTRAP REVISION HISTORY 


; REV DATE CHANGE 

21.0 12-JUL-78 INITIAL ISSUE 

; 1.1 17-NOV-78 MAKE COMPATABLE WITH XXODP- 

; 1.2 12-JUL-82 MODIFIED TO SUIT VAX ASSEMBLER 

3 1.3 29-MAR-83 WHEN TRYING TO BOOT TO UNIT OTHER 

: THAN # AND UNIT 0 NOT ON BUSS, A 
: HALT AT 216 OCCURS 

; 21-FEB-84 V2 CHANGE STACK AND MON SIZE 


-— -- - te —_—— © —— eee 


. PAGE 
.SBTTL 


RBBOOT: 


RBCSA: 
START: 


STAPT 1: 


5$: 
10$: 


15$: 


20$: 


253: 


70$: 


GS 


BOOTSTRAP 
.NLIST CND 

“LIST MEB 

RBCS1 = 0 

ReWwlti‘s «2 

RBBA = 4 

RBDA =6 

RBCS2 = ‘10 

RBDS = 12 
RBDC = ~34 

BEGIN = 1046 

MONCNT = 20000-256 ;SKIP BOOT BLOCK 

NOP 
BR START ;START BOOT ROUTINE 

-WORD 6 

HALT ; TRAP CATCHER 

.WORD 12 ;RESERVED INSTRUCTION ERR 
HALT ; TRAP CATCHER 

.BLKB 4 

.WORD 176700 ;RJPO4 DEFAULT CSR ADDRESS 
NOP 
BR START1 

BLKB 12 

WORD 0,0 

BLKB 24 
MOV +2 UP STACK 
MOV RBCSA,R5 ;GET RBCS1 ADDRESS 
MOV 23,(R ;D0 PACK ACK TO SET VV BIT 
MOV RBCS2(RS),R2 ;GET UNIT NUMBER 
BIC #177770, 
MOV #40, RBCS2(R5) ;CLEAR CONTROLLER 

R2,RBCS2(R5) ;SET UNIT NUMBER 
200 sREADY? 


B 2 
TSTB RBDS(R5) 
15$ 


MOV #-MONCNT ,RBWCC(RS) 
MOV #1000, RBBACRS) 
MOV #5003+1,RBDACRS) 
MOV #0,RBDC(RS) 


MOV #71,(R5) 

BIT #100200, (R5) 
bEQ 20$ 

BP. 30$ 

MOV (R5),RO 

MOV RBCS2(R5),R1 
HALT 

BR 5$ 

MOV R5,R1 

JMP a*BEGIN 


‘ERROR 

sDRIVE READY? 

'SET UP WORD COUNT 
LOAD AT LOCATION 1000 
sBLOCK @ OF MONITOR 
;D0 READ COMMAND 
:DONE OR ERROR? 


; SAVE Ag 


‘OK, TRY AGAIN 
‘PUT CSR ADDRESS IN DRIVER TABLE 
:START UP HIMON 


A A Lc, NN i A ye 


SEQ 0032 


HS 


SEQ 0033 


Appendix: B - Assembly and Linking Instructions 


The Driver and Boot must be merged together and then 
assmbled as a .MAC file. They should be maintained 
seperetly as shown in appendix A, that is they have 

their own revision blocks. Assembling them together | 
helps to eliminate double references that would otherwise 
occur. References to an absolute location by the BOOT code 
must be done via an offset from BCODE:, which will be at 
absolute zero during the boot operation. 


Command file to create a XXDP V2 DB DRIVER 
MCR MAC DB,DB/CRF/-SP=MACROM.MAC ,DB.MAC 


Set the address limits for the driver and create 
e binary file 


MCR TKB 
DB/NOMM/NOHD/ SQ, DB/-SP=DB 


/ 
PAR=DUMMY :0: 3200 
STACK=0 


/ 

$ WRITE SYSSOUTPUT “ Now type TKBBIN <CR> , “ 

$ WRITE SYS$OUTPUT ” When prompted for the file name enter DB.” 
$ WRITE SYSSOUTPUT " will create a driver called DB.BIN .” 


MPtaeretaertae raetartea 


<< = — mm. -_— ee _—-o —_—— ae « 


Ls 


; XXDP* Version 2 


Equate Definitions 


DEVICE COMMAND CODES 


RED$FN 


DEVICE 
BBSUP $ 
NORENS$ 
NODIR$ 


TAPED$ 
REF ONS 
MULUNS 


DEVICE 


BOTTPS$ 
TMKTP$ 
EOTTP$ 


Wher oO 


w 
o 
Ow 


CODE BYTE 


ere 
| ee 


40 ; 
100 $ 


; igo SUPPORT 


see DEVICE and BRING ON LINE 


WRITE 
RESTORE FUNCTION for _ SM 
REFORMAT SINGLE DENSITY 


REFORMAT DOUBLE DENSITY 

TAPE - PREPARE 

TAPE - REWIND 

TAPE - REVERSE SPACE 

TAPE - WRITE HEADER 

TAPE - READ HEADER 

TAPE - SKIP to EOF 

TAPE - WRITE EOF 

TAPE - SKIP to EOT 

TAPE - RETURN STATUS C 

RETURN ITY (0 = LOW, 1 = HIGH) 
T BLOCK # from SEC 


COMPUT BL 
WRITE absolute SECTOR 
READ absolute SECTOR 


NAME FILE 


TAPE CANNOT RE 
; NOT A DIRECTORY DEVICE 


IS A TAPE DEVICE 
SUPPORTS SINGLE/DOUBLE DENSITY FORMAT 
DRIVER SUPPORTS MULTIPLE UNITS/DRIVER 


RETURNED STATUS BYTE 


2 ; 
4 ; 
10 : 


TAPE IS AT BOT 
TAPE IS AT TAPE MARK 
TAPE IS AT EOT 


— - - 


SEQ 0034 


JS 


SEQ 0035 


The Device Type Code (DTC) is placed into byte location 41 by the 
monitor every time a binary file is run. This byte is then | 
e 


designated the “load medium indicator”. DTC's are assigned as 
follows: 
DTC DEVICE Type XXDP+ Version Notes 
0 rt or * cian ee 
SURE" bPetac 3 
2 RKOS rot ie 
ae Hy 
magtape : 
5 TA11 (cassette) Lea 
$ fin etnin ae 1.3 2.0 
10 RXO1 "Floppy i ee 
11 RPO4/R505/RPO06 isk) Lee 2.0 
12 RSO3/RSO4 (disk) 1.3 
13 RKO6/RKO7 (disk) Se 2.0 
1 RLO1/02 (disk) 1.3 2.9 
15 RXO02 (disk 1.3 2.0 
16 RMO2/RMO3 (disk) 2.0 
17 TUS8 (cassette i.e 2.0 
20 TUS8/PDT11 (cassette) 1.3 
21 TS04 (t 1.3 2.0 
22 TM78 (tape Bi 
23 UDA (disk MSCP) ioe 2.0 1 
24 TR79 (tape Lew 
25 RD/RXSO (disk) 1.3 2.0 i 
26 RC25 (disk) 1.3 2.0 1 
27 TK50 oe MSCP - TMSCP) ee 2.0 


I I Re ee ee ee ee eee ee 


1. These are MSCP class devices and under XXDP V2 are 
handled by one driver which uses DTC = 23 
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